Date: Tue, 31 May 94 04:30:02 PDT From: Advanced Amateur Radio Networking Group Errors-To: TCP-Group-Errors@UCSD.Edu Reply-To: TCP-Group@UCSD.Edu Precedence: Bulk Subject: TCP-Group Digest V94 #105 To: tcp-group-digest TCP-Group Digest Tue, 31 May 94 Volume 94 : Issue 105 Today's Topics: Digital Communitations? ... When?? Gracilis (2 msgs) Mail failure More RSPF Help needed..... nos-bbs mail address hosed? (2 msgs) Send Replies or notes for publication to: . Subscription requests to . Problems you can't solve otherwise to brian@ucsd.edu. Archives of past issues of the TCP-Group Digest are available (by FTP only) from UCSD.Edu in directory "mailarchives". We trust that readers are intelligent enough to realize that all text herein consists of personal comments and does not represent the official policies or positions of any party. Your mileage may vary. So there. ---------------------------------------------------------------------- Date: Tue, 31 May 94 09:30:04 UTC From: eb3aod@albinyana.etse.urv.es Subject: Digital Communitations? ... When?? To: tcp-group@UCSD.EDU I read a lot of time, papers, RFC, about "Packet Radio" and something the author says "digital communication" when i think this is a wrong sentence. We do (the om's) "Packet Radio". This kind of communication is analog not digital so we use a modem ... Am i wrong about this?? Why does a lot of people say "Digical Communication" when refers the "Packet RAdio"?? Saludos de Curro eb3aod e-mail : curro@etse.urv.es AX25 : eb3aod@ea3rdt.eat.esp.eu "Data Highway" : In my Dreamland ... ------------------------------ Date: Mon, 30 May 1994 12:03:30 -0500 (CDT) From: ssampson@sabea-oc.af.mil (Steve Sampson) Subject: Gracilis To: tcp-group@ucsd.edu The Gracilis equipment is well designed and simple to operate with the given software. Where I would caution anyone is that they not be mere operators. These cards require configuration, and sooner or later you will want to upgrade your NOS and port the Gracilis drivers to it. In this case you are on your own. There is no user group to share experiances. I purchased a packetwin when they first came out. It was a good card but after a couple years of fighting my NOS blowing up I decided to get a 9600 KISS modem. The KISS part of NOS works better than the Gracilis drivers (or they did back then). I don't know what Gracilis is shipping for drivers today, but it's probably the same code as before, and requires NOS. I've since graduated from NOS since the program takes over the whole PC, to Unix which interfaces to KISS much better than low level interrupts from an SIO chip (a driver which I couldn't write, and no one else has). Gracilis cards would seem to be a waste at 9600, but better suited to the 56k radio modem and a dedicated PC. The packetten on the other hand is another quality hardware device that incorporates NOS on a card. This is probably the highest tech device there is in Ham radio. It works. I hear there is a plug in card for the PC but I haven't seen it in ads or my mailbox. As a past owner of their equipment I can say that support is not one of the areas they feel responsible for. Not even a newsletter now and then. If you look at their prices, see that they're high, and assume you will get a lot of support, you will be wrong. As you look back in the ARRL Computer Conference papers you will see a lot of fancy hardware proposed and designed. All of it is vaporware and unavailable. Gracilis is the only company that seems to be doing anything in hardware in the United States that can move a product from design to production. -- Steve ------------------------------ Date: Mon, 30 May 1994 16:28:59 -0500 (CDT) From: ssampson@sabea-oc.af.mil (Steve Sampson) Subject: Gracilis To: bsa@kf8nh.wariat.org (Brandon S. Allbery) > > Dunno where you've been, buit there are currently Linux drivers for SCC cards, > the Ottawa PI2 card, and I'm working on PackeTwin drivers. > Where are they available for FTP? Thanks. -- Steve ------------------------------ Date: 30 May 1994 09:24:09 EST From: "POSTMASTER" Subject: Mail failure To: TCP-Group@UCSD.EDU Date: Sat, 28 May 94 10:41:37 CDT From: route66@ddl.chi.il.us (System Administrator) Subject: Gracillis To: tcp-group@ucsd.edu I have been looking into buying Gracillis for 9600 baud packet. Has anyone ever tried it..and if so, how is it on TCP/IP? Also, I'd rather not spend $1,000 for Gracillis new..by chance does anyone out there have a used one setup they wanna get rid of? Thanks, Greg Kaiser - N9TOL ------------------------------ Date: 29 May 1994 09:04:09 EST From: "POSTMASTER" Subject: Mail failure To: TCP-Group@UCSD.EDU Date: Sat, 28 May 94 04:56:05 CST From: Jack Snodgrass Subject: More RSPF Help needed..... To: tcp-group mailling list We've been tearing out my hair trying to figure out how to link 2 RSPF routers that use an IP Router to communicate. It seems like RSPF should work and NOT require that every station in the network Run RSPF, but we just can't figure out how to make it work. We've got: -------- -------- -------- kf5mg <---440---> wb5tey <---144---> k5rw -------- -------- -------- kf5mg and k5rw are running RSPF. When either one sends out it's RSPF broadcast, the other station can't hear it because they're on separate networks. Is there an easy way to fix this? We've set up and AXIP link between the two RSPF routers and set up the routes between k5rw and kf5mg to use wb5tey. Now they can hear each others RSPF broadcast, but the RSPF added routes are screwed up. All of k5rw's RSPF added routes on kf5mg show that they route through k5rw on 440 instead of wb5tey. All of kf5mg's RSPF added routes on k5rw show that they route through kf5mg on 144 instead of wb5tey. I'm guessing that the reason the routes are screwed up is that RSPF assumes that since it can 'hear' the station direct ( because of the axip link ) the RSPF added routes assume that they go direct to the remote system and don't take into account any pre-existing routes set up between the two RSPF routers. Next, we set up an ENCAP link in hopes that if the AXIP link was run over the ENCAP link the RSPF added links would use the ENCAP link routes. That didn't work either. The AXIP stuff goes over the ENCAP route, but the RSPF added routes still ignore the IP router that's in between the two RSPF routers. Someone is probably going to suggest that wb5tey ( in our example ) run RSPF. Yes... that will work, but I want/need to figure out this problem. Once we get this working, we'll add RSPF to both of our Internet Gateways. There's no way to get the network routers between the two gateways to run RSPF. Anyway.... either there is something basic that I'm missing or RSPF is really un-usable in a standard network and I can't see how one can really be using it. Any info/help/suggestions ( preferably working ) would be appreciated. Thanks. 73's de Jack - kf5mg Internet - kf5mg@kf5mg.ampr.org - 44.28.0.14 AX25net - kf5mg@kf5mg.#dfw.tx.usa.noam - home (817) 488-4386 Dialup - kf5mg@tcet.unt.edu - work (looking for) ============================================================================== = === Buffalo's new area code.... 044.... "Deal with it" == = ============================================================================== = ------------------------------ Date: Sat, 28 May 1994 16:28:01 -0400 From: goldstein@carafe.tay2.dec.com Subject: More RSPF Help needed..... To: tcp-group@ucsd.edu Jack, > We've got: > > -------- -------- -------- > kf5mg <---440---> wb5tey <---144---> k5rw > -------- -------- -------- > > kf5mg and k5rw are running RSPF. When either one sends out it's RSPF >broadcast, the other station can't hear it because they're on separate >networks. Is there an easy way to fix this? Not an easy way... This would have been solved fairly easily had RSPF2.2 been implemented. RSPF2.2 is a spec that makes clear that "normal" IP rules of "subnets" do NOT apply, and therefore you can create adjacencies using any kind of lower-layer (subnetwork in the OSIRM sense) connection and RSPF will use them if appropriate. But the code in NOS does not override IP's routing function, and treats RSPF node groups as IP subnets, which they ain't. I don't know what hackery has been done recently to allow faking things, but it's all half-way. Note that RSPF was designed to run on routers, but not be needed on end stations. Your example is of course the opposite, and tries to use intellgent end systems to get past a lack of intelligent routers. Perfectly sensible but since I don't personally _use_ any of the RSPF variants currently implemented, I can't tell you what works. If somebody would take the 2.2 spec and really implement it... Naaah, we're hams. Why do it right when a quick and dirty early hack is available? Why should routing be different from the "202" modems? :-( (sig)> Buffalo's new area code.... 044.... "Deal with it" I must be missing something... fred k1io ------------------------------ Date: Sat, 28 May 94 11:21:03 CST From: fchavarr@udgserv.cencar.udg.mx (Fco. J. Chavarria -POLITEC) To: tcp-group@UCSD.EDU unsub fchavarr@udgserv.cencar.udg.mx ------------------------------ End of TCP-Group Digest V94 #103 ****************************** ------------------------------------------------------------------------------ ------------------------------ Date: Sun, 29 May 94 05:48:00 -0000 From: mikebw@bilow.bilow.uu.ids.net (Mike Bilow) Subject: More RSPF Help needed..... To: tcp-group@UCSD.EDU Cc: kf5mg@kf5mg.ampr.org JS> We've been tearing out my hair trying to figure out JS> how to link 2 RSPF JS> routers that use an IP Router to communicate. It seems like RSPF should JS> work and NOT require that every station in the network Run RSPF, but we JS> just can't figure out how to make it work. I understand your problem exactly. There really are no easy ways to do what your want, but it should be possible. However, it is an involved thing and I don't want to sit here typing away nonsense before I think it through. A lot of these kinds of problems are a result of features in the formal RSPF spec remaining unimplemented. RSPF was intended to function as an interior routing protocol within the autonomous system which is Amprnet. The expectation was that all routers woul d be running the routing protocol. This is not an unreasonable expectation, and it applies pretty much equally to any other routing protocol besides RSPF. En d nodes which have no routing responsibility are not usually expected to run RSPF, but that is a very different thing. -- Mike ------------------------------ Date: Mon, 30 May 1994 09:05:19 CET From: "Jack Stiekema" Subject: TCP-Group Digest V94 #103 To: Advanced Amateur Radio Networking Group >> We've been tearing out my hair trying to figure out how to link 2 RSPF >>routers that use an IP Router to communicate. It seems like RSPF should Maybe a silly question, but what is RSPF? Kind regards, Jack Stiekema Product Manager Connectivity +----------------------------------------------------+ | Victron bv POB 31 9700 AA Groningen Holland | | Phone: +31 50 446222 Fax: +31 50 424107 | | Email: jack@victron.nl Internet: 193.78.6.6 | | Home: +31 5980 80498 pe0mot@pe0mot.ampr.org | +----------------------------------------------------+ ------------------------------ Date: Mon, 30 May 1994 10:43:38 MET From: betaille@lurvax.lure.ups.circe.fr Subject: unsub To: tcp-group@ucsd.edu unsub betaille@lure.ups.circe.fr tcp-group ------------------------------ End of TCP-Group Digest V94 #104 ****************************** ------------------------------------------------------------------------------ ------------------------------ Date: Mon, 30 May 94 08:23:00 -0000 From: mikebw@bilow.bilow.uu.ids.net (Mike Bilow) Subject: More RSPF Help needed..... To: tcp-group@UCSD.EDU Cc: kf5mg@kf5mg.ampr.org JS> On a different subject.... I think that you were JS> talking about putting together JS> a packet driver that ran in an OS/2 dos box and would JS> talk to another packet JS> driver in a second OS/2 Dos box. Was that you? I was actually talking about making a shim for G8BPQ that would allow BPQCODE to run in a DOS window and communicate with separate processes running in their own DOS windows. This would allow using G8BPQ in connection with OS/2 much the same way as it is commonly used with DESQview. However, I was not planning to implement this as a packet driver. JS> How much do you JS> know about OS/2 programming? I'm reading up on it. A fair amount. There are some other people around, particularly Walt Corey, kz1f@legent.com, who could also be of help. JS> One JS> question I have and JS> can't find an answer to is 'How can a DOS Box get JS> access to OS/2 pipes and JS> semaphores? The proper architecture -- and I'm not saying it is the only way to do it -- is to write a Virtual Device Driver that presents some convenient API to the DOS program. The VDD would be able to manage OS/2 IPC resources, including semaphores, pipes, queues, and even shared memory. You have to be especially careful with pipes, since they can be non-local (network) resources. JS> Also... what OS/2 'features' can the DOS JS> Box utilize? I'm thinking JS> that you could write a OS/2 packet server that runs in JS> an OS/2 session. Then JS> your DOS Box Packet drivers would talk to this system JS> using pipes or shared JS> memory. The OS/2 Packet Server would handle getting the JS> data to the other DOS JS> Box. Anyway.... can't make any progress on this till I JS> figure out how to give JS> a DOS program accesses to OS/2 stuff. The packet driver architecture is DOS-specific, and you cannot make such a thing run as an OS/2 session. What you can do, if you are committed to the packet driver API for some reason, is write a VDD that presents the packet driver API to a DOS process, and translates or emulates that API to something else that is OS/2 compatible, preferably NDIS. This kind of thing probably exists, but I don't know about it right off. It would also be possible to write the VDD such that different DOS processes could be given the illusion of exclusive access to their own packet driver, provided that some acceptable means for sorting out which process owns which frames can be developed. JS> Lastly.... If you know much about OS/2 programming.... JS> any idea how to talk to JS> the NDIS drivers from a 'C' program? Thanks. This depends upon the exact implementation of your NDIS layer. The usual method is to be given a device driver with the *.OS2 naming convention, and a*.NIF text file which provides the necessary information to access the driver, such as device name. It is actually extremely rare that an applications developer would want to access the NDIS driver directly, since you are usually going through LAPS ("LAM Adapter Protocol Support") or NTS/2 ("Network Transport Services/2") or whatever it is called now to get to the network. If you are implementing the protocol stack yourself, the best way is to write a reentrant DLL and export whatever API you need. At minimum, it would be prudent to go through LAPS, which does most of this low-level work for you. Also, LAPS is the only way to guarantee properly shared use of the LAN between different protocol stacks. Maybe if you gave me a better idea of what you were trying to do, I could be more informative. -- Mike ------------------------------ Date: Tue, 31 May 94 04:16:00 -0000 From: mikebw@bilow.bilow.uu.ids.net (Mike Bilow) Subject: nos-bbs mail address hosed? To: tcp-group@ucsd.edu Cc: lyndon@unbc.edu LN> Using a needless MX adds to innefficiency - you have to do the A record LN> lookup anyway to deliver to the machine. If there is no MX record at all, then DNS queries will be sent for MX of"hydra.carleton.ca", "*.carleton.ca", and "*.ca" before a request for an A record is made. Since all three queries will fail to return any resource records, they must all be responded to by an authoritative name server for their respective domains, as negative responses cannot be cached. If there is an MX record for "hydra.carleton.ca", then the process will move immediately to obtaining the A record, and at least two queries will be avoided. Also, if the NS records needed to make the MX queries are not known, then additonal queries will be generated to get them. With a proper MX record in this case, all of the queries will be to the same name server, and positive responses can be cached. -- Mike ------------------------------ Date: Mon, 30 May 1994 23:58:16 -0700 (PDT) From: Lyndon Nerenberg Subject: nos-bbs mail address hosed? To: Mike Bilow > If there is no MX record at all, then DNS queries will be sent for MX > of"hydra.carleton.ca", "*.carleton.ca", and "*.ca" before a request for an A > record is made. Is this the case? We're crossing boundaries between DNS and MTA implementation here, but it seems to me that any MTA that would query *.ca MX's when looking for hydra.carleton.ca is broken. A reasonable search tree would be: * MX for hydra.carleton.ca * A for hydra.carleton.ca * MX for *.carleton.ca * MX for *.ca and I would disagree with the latter as a matter of principal, since you're *very* unlikely to find a wildcard MX for a top level domain. Much of this depends on how flexible (smart?) your resolver routines are. > Also, if the NS records needed to make the MX queries are not known, then > additonal queries will be generated to get them. With a proper MX record in > this case, all of the queries will be to the same name server, and positive > responses can be cached. True, but your MTA could do the initial DNS query asking for everything about hydra.carleton.ca and get back both the MX and A records (if they both existed) in a single response (modulo UDP datagram size limits). (Sorry to pick on you, Barry :-) --lyndon ------------------------------ End of TCP-Group Digest V94 #105 ******************************